031 Основы мониторинга

Слайды на отдельной странице

О чем лекция

• Цели мониторинга
  • Детектирование
  • Понимание причин сбоя
  • Долгосрочное планирование, выявление трендов
• Логи
  • Структурированные/Неструктурированные
  • Логи, как API
• Метрики
  • Типы, форматы
  • Быстро меняющиеся метрики/метрики использования ресурсов
  • Долгосрочное хранение метрик. Downsampling.
  • OpenMetrics
• Дашборды
• Алерты/Триггеры/Пейджи
  • Определения, примеры реализаций
• Трейсинг * OpenTracing, OpenTelemetry

Цели мониторинга

Мониторинг – комплекс мероприятий, которые направлены на:

Детектирование сбоев.

Важно отделить периоды, когда системы работали исправно, от периодов, когда они не работали. Задача формулируется просто, но очень сложна в реализации — проблемы начинаются в самом начале, когда пытаешься сформулировать, что значит, что "приложение работает исправно".

Если ошибка только у 1% пользователей, это скорее работает или уже нет? А если у нас 10.000.000 пользователей, то 1% даст нам 100000 пользователей с проблемами и они способны перегрузить в свою очередь ваш коллцентр, или испортить вашу репутацию негативными постами с соц. сетях.

И подобные дилеммы приходится решать на каждом шагу. И даже решив их все остается довольно сложная и трудоемкая задача имплементации. В Тинькофф нам пришлось для этого написать собственный сервис — Slaser, так как никакого опенсорсного или доступного к покупке мы не нашли.

Подробнее про это — в следующей лекции.

Поиск причин во время сбоя

Второй задачей мониторинга является задача поиска причин во время сбоя. Современные системы очень сложны и часто состоят из десятков или даже сотен взаимодействующих между собой микросервисов. Если в них что-то идет не так, то понять, что именно, довольно сложно и нужно собирать много внутренних показателей с их визуализацией, чтобы мочь быстро разбираться в происходящем.

TODO: нужна картинка с причиной сбоя

Сбор информации для регулярных улучшений

Разработчикам, аналитикам, архитекторам нужно много данных о жизни приложения, чтобы понимать, что можно улучшить, даже если сейчас сбоя нет. Это позволяет оптимизировать процессы, улучшать архитеутуру и т.п.

TODO: картинка с улучшением было/стало

Выявление трендов

Важно уметь сравнивать поведение приложения в прошлом и в настоящем. Есть много медленных изменений: как постепенно меняется нагрузка со стороны пользователей — медленный дренд может совершенно потеряться за дневной сезонностю, но на интервалах в год может быть хорошо заметным.

Другие примеры: выявление постепенного замедления работы приложения по мере добавления новых функций — каждая функция может замедлять приложение незначительно, иначе вы это заметите сразу, но за год может накопиться много всего и может оказаться, что ваше приложение уже в два раза медленнеее для ваших пользователей, чем год назад. Так же надо следить, за постепенным ростом количества данных в ваших системах и исчерпание других ресурсов (место на диске всегда заканчивается неожиданно!).

TODO: нужна картинка с трендом и сезонностью.

Формы мониторинга

Метрики

Метрики – серии числовых значений, обычно, через равные интервалы времени. Как правило пишутся раз в минуту, но может быть чаще и реже. Пример: отслеживание количества пространства на жестком диске в байтах — каждую минуту имеем новое значение и можем отслеживать, как оно меняется со временем.

Мерики имеют имя. Обычно оно составное и содержит описательную часть, например, "место на диске" и часть сообщающую откуда эта метрика, что есть на каком конкретном сервере или виртуальной машине считается это место.

Распространены две схемы получения такого составного имени: позиционное и с тегами. Позиционное имя состоит из нескольких частей разделенных обычно точкой и на первой позиции имеем имя метрики, на втором, например, датацентр, на втором имя хоста, на третьем название диска, например disk_space_available.dc-1.webserver-1.hda. В этом случае инженеры договариваются что будет стоять на каком месте и этому надо следовать.

Во втором случае у нас есть именованные теги для всех этих сущностей и записывается это примерно так:

disk_space_available{dc=dc1,server=webserver-1,disk=hda}

Детали немного отличаются от системы к системе, но все более-менее следуют одной из этих двух схем.

Для каждого сочетания тегов или позиционных параметров у нас получается ряд чисел привязанных ко времени и на основании анализа этих временных рядов мы делаем дальнейшие выводы.

Типы метрик по поведению

Для удобства анализа выделили несколько типов метрик в зависимости от их поведения.

Gauge

Метрики, меняющие значения произвольно. Используются, например, чтобы определить, сколько есть свободной оперативной памяти или как меняется температура процессора.

Наиболее общий тип метрик с произвольным поведением.

Counter

Числовой ряд, который постоянно увеличивается. Не обязательно это именно счетчик, главно, что метрика монотонно возрастает. Если значения уменьшаются, значит, произошел рестарт приложения. Увеличивающиеся метрики удобно применять в расчетах. Пример: Вы хотите понять, сколько запросов обрабатывает приложение. Собирая данные раз в минуту, вы будете получать показатель прироста.

Гистограммы

Используются, например, для сбора данных о времени выполнения запросов. Первый вариант гистограммы – buckets. Мы создаем шкалу типичных значений, например, 5, 10, 15 миллисекунд и определяем, сколько запросов было обработано в пределах этих промежутков времени. Затем нужно изучить статистическое распределение показателей за разные периоды работы системы. Трудность этого подхода – грамотно выбрать шаг шкалы. Он должен соответствовать частоте изменения самой метрики. При этом метрика может меняться по-разному в зависимости, например, от времени суток. Второй вариант – quantiles. Обычно считают медиану, 95-й перцентиль и 99-й. Сложность – нужно накопить большой объем информации. Обычно это доступно в библиотеках для разных языков программирования. Важно понимать, каков смысл показателей, которые заложены в библиотеку.

Сбор метрик

Чтобы получить эти значения их должен, кто-то куда-то писать. Для хранения и обработки метрик есть множество систем со своими особенностями. Ниже некоторые популярные системы, но на самом деле их намного больше:

• Prometheus
• Victoria Metrics
• InfluxDB
• Graphite
• Zabbix
• Nagios
• Datadog

Есть стандартные системные метрики. Если говорить о Prometheus, то есть приложение node_exporter. С его помощью приложение должно рассказывать о своем внутреннем состоянии.

Типы метрик:

• Counter –
• Gauge –
  Частота сбора данной метрики должна быть ниже частоты изменения показателя, который вы изучаете.
• Гистограммы.
  Для сбора информации метрик используются две модели – Push (заталкивание) и Pull (вытягивание). Push – приложение подключается к системе и записывает значения с указанным интервалом. Система их сохраняет, посылает запросы и анализирует значения. Интервал настраивается в нашем приложении. Приложение может перегрузить сбор метрик, если все метрики собираются, например, в нулевую секунду каждой минуты. Нагрузку нужно распределять равномерно в течение минуты. Pull – сейчас более популярная модель. Сборщик – отдельно стоящее приложение с указанным интервалом ходит по нашему приложению, делает http вызов и получает значения. Если компания большая, то нужна целая «ферма». При неправильной настройке сборщики высокочастотных метрик могут перегрузить приложение запросами.

Программы используют разные языки запросов. Как использовать метрики С помощью данных метрик с использованием, например, системы Grafana можно делать красивые визуализации. Можно рисовать распределение во времени, использовать индикаторы со стрелками. На основании анализа метрик строится алертирование - настройка уведомлений, которые приходят, когда показатель выходит за установленные пределы.
Основные проблемы метрик:

• Невозможно постфактум путем пересчетов получить то, что вы изначально не закладывали в метрики. Этим метрики отличаются от логов, в которых можно хранить информацию о каждом запросе.
• Измеряемых метрик становится слишком много. В каждой организации много сервисов, каждый из которых хочет выставлять множество метрик. Большое количество метрик может перегрузить централизованную систему мониторинга. Приходится вводить лимиты и придумывать системы сдерживания мониторинга. Однако не все системы обработки метрик позволяют ввести лимиты и сделать это безопасно. Очень распространенная проблема – общая система мониторинга убивается одним из его участников. Если вы выпустили версию приложения, которое дает намного больше метрик, чем его предыдущая версия, это может стать поводом для отката релиза.

2. Логи Логи как инструмент мониторинга появились раньше метрик. Лог - метка на временной шкале, снабженная произвольной информацией о том, что за событие произошло, почему произошло. Раньше информация оформлялась в виде текстовых файлов с использованием разделителей. Сейчас популярно структурированное логирование – JSON, TSV, protobuf . Есть способ tab-separated values. Пример лога: Вам пришел запрос. Вы записываете, что это за запрос, откуда он, каковы параметры, сколько потребовалось времени на обработку. Раньше логи использовались для анализа в ручном режиме человеком. В современных больших системах они используются для машинного анализа. Данные из логов можно преобразовывать метрики. Преимущество – эти метрики можно пересчитать, потому что исходная информация сохранилась в логах. Логи – один из способов сделать служебный API. Вокруг логов выстраиваются автоматизированные процессы. Одни системы порождают логи, другие системы с использованием этих значений совершают автоматические действия. За логами нужно внимательно следить. Нужно контролировать совместимость изменений. Хранение логов:

• в файлах на сервере
• Systemd Journal
• централизованные агрегаторы: *ElasticSearch *Grafana Loki *Splunk Как логи попадают в централизованные системы:
• запись на диск, затем в агрегатор логов. В процессе передачи с диска в агрегатор возможно обогащение логов
• запись напрямую в агрегатор логов. Преимущества – не задействован диск, не нужно мониторить процесс передачи. Недостаток – нужно подстраховаться на случай, если агрегатор недоступен при сбое. Можно копить логи, используя локальные диски. Это усложняет написание приложений. На процессинг логов уходит на удивление много ресурсов. Например, приходит запрос по API. Он несложно обрабатывается, но при этом делается несколько записей в логи, по длинной цепочке отправляет в систему процессинга логов. Мы стремимся делать максимально легковесным процессинг логов. Преимущество - приложение делает готовый лог. Во время сбоев приложения пишут во много раз больше логов, чем в обычное время. Системы могут не все писать об успешных транзакциях, но об ошибках пишут абсолютно все. Растет и количество записей и их размер. То есть система, которая должна помочь разобраться со сбоем, может сама не справиться с нагрузкой. В итоге на основной сбой накладывается сбой мониторинга. Здесь требуется грамотное проектирование. Как логи, так и метрики имеют тенденцию расти. Если от релиза к релизу резко поменялось логирование (количество их возросло), это может стать поводом для отката изменений. Как уменьшить количество логов В сильно нагруженных системах не обязательно писать все логи. Логи можно ассемблировать, то есть логировать не каждый запрос, а каждый десятый, сотый или тысячный в зависимости от нагрузки. Обычно 10% запросов, а иногда и 1% вполне достаточно для того, чтобы сделать выводы. 3.Трассировка запроса Сложные системы обычно состоят из нескольких тесно взаимодействующих подсистем. Конкретный запрос от пользователя проходит через массу микро-сервисов, которые делают согласованную работу. Поэтому удобно собирать логирование со всех сервисов. Если все запросы имеют сквозной идентификатор, по нему можно собрать полный жизненный цикл конкретного запроса. Такой прием называется трассировкой запроса. Существуют специализированные системы для трассировки запроса. Проекты OpenTracing и OpenTelemetry работают над стандартизацией этой процедуры, пытаются провести ее через все языки программирования. Реализация бэкендов:
• Jaeger
• Zipkin
• ElasticSearch Интерфейс отображает прохождение запроса через системы. Это очень помогает в отладке. Такие системы логируют выборку запросов или держат все запросы недолгое время, а для дальнейшего хранения делают выборку. Вывод: сочетая метрики, логи и трассировку можно получить большой объем информации про ваши системы. Если она спроектирована с умом, то можно решить четыре основные задачи:
• детектирование сбоев
• помощь по исправлению во время сбоя
• отладка и получение инсайта для разработчиков
• наблюдение долгосрочных трендов и планирование.

Цели мониторинга

Сложные IT системы требуют постоянного наблюдения за своим состоянием. Делается это с тремя целями:

Определить, что система функционирует в соответствии с дизайном. Целью данного мониторинга является замеметить отклонения от нормального функционирования и привлечь внимание инженера (алерт, пейдж), чтобы тот смог вмешаться, проанализировать ситуацию и восстановить работоспособность системы. На основании данных с этого мониторинга, собирая статистику, мы можем сделать выводы насколько надежна наша система. Обычно сдесь у нас анализируется минимально достаточное количество сигналов от приложения с тем, чтобы просто понять нормально ли оно функционирует прямо сейчас.

Найти источник неполадок. Здесь нам требуется намного больше данных и сигналов, чтобы точно установить технические (связанные с кодом и железом) причины сбоя и устранить их. Здесь нам нужны сигналы со всех уровней: от железа, оперционных систем, виртуализации, а так же внутренние важные показатели работы приложения. Иногда по этим данным мы можем поймать только зарождающуюся проблему и привлечь внимание инженеров, чтобы они успели принять меры по предотвращению сбоя. Во время сбоя мы преимущественно используем данный мониторинг.

Долгострочное планирование и выявление важных трендов. Некоторые сигналы могут храниться несколько лет, с тем чтобы выявлять долгосрочные тренды и использовать это для планирования закупок железа и подобных вещей. Так же сигнал мониторинга может быть использован для сравнения производительности разных версий приложения и вообще отличия между версиями, например, в характере или количестве потребления разных ресурсов.

Формат получаемых данных

Приложения предоставляют данные как правило в двух форматах: это логи и метрики.

Логи

Логи представляют собой информацию о некотором событии. Включают себя информацию о времени события, источнике (хост и приложение) и сами данные о событии. Дополнительно логи обычно содержат информацию об источнике: имя хоста, название приложения, имя виртуальной машили и подобную информацию.

Логи могут быть более или менее структурированными, когда часть информации написана простым текстом и предполагает, что ее будет читать человек.

TODO(d.maslennikov): примеры логов

Для упрощения автоматизированной обработки логов их лучше делать полностью структурированными, например в JSON. Сейчас автоматизированная обработка более важна, чем просто чтение логов.

Есть разные подходы к тому, как приложение предоставляет логи:

• писать логи на стандартный вывод в виде текстовых данных
• писать логи в один или несколько файлов
• отправлять логи напрямую в сервис для агрегирования и анализа логов.

Как правило логи имеют дополнительную метаинформацию об уровне критичности: TRACE, DEBUG, INFO, WARNING, ERROR и CRITICAL. Это делается для того, что как правило DEBUG логов очень много и требуется существенные резурсы, чтобы их порождать и еще большие, чтобы их анализировать. В таком случае приложения предоставляют возможность переключать уровни, чтобы можно было оставлять небольшое количество логов большую часть времени, но иметь возможность временно увеличить детализацию, если это необходимо.

Логи всегда содержат метку времени. Нет ничего хуже, чем писать время без временной зоны. Особенно сейчас, когда все работают удаленно. Для простоты пишите логи строго всегда в UTC и все равно явно указывайте это, если используете текстовый формат для временных меток (например, как в RFC3339).

Если приложение пишет логи на стандартный вывод, то предполагается, что какая-то ситема вне приложения будет агрегировать и анализировать логи.

Если мы пишем логи в файлы, то надо не забывать, что они могут заполнить все доступное пространство на дискеи привести к сбою. Даже до этого, лог файлы могут становиться огромными и их будет трудно анализировать. Как правило в этом случае делается ротация логов, когда время от времени приложение начинает писать логи в новый файл, а старый может храниться какое-то время и потом быть удален.

Каким бы образом приложение ни предоставляло логи, в современном мире они как правило попадают в специализированную централизованную системы, которая хранит информацию со всех нод всех приложений. Есть много Cloud сервисов, а так же проприетарного и открытого софта для этого. Раньше логи часто просто хранились на машине, где они и были продуцированны и их анализировали заходя на машину (SSH) с помощью консольных утилит (например grep), но сейчас это скорее запасной вариант, на случай крупного сбоя, когда недоступна даже система аггрегации логов.

Обработка логов может занимать очень много ресурсов. При неправильной организации процесса она легко может занимать в разы больше ресурсов, чем та полезная нагрузка, которую производит ваш сервис. Часто во время сбоя приложение начинает писать намного больше логов. Например в нормальной работе сервис может производить одну короткую запись на один входящий API вызов или даже на производить вовсе, а во время сбоя на каждый запрос может порождаться несколько огромных детальных записей. Это порождает серьезную нагрузку на систему логгирования и может вывести ее из сроя, тогда как во время сбоя она нужнее всего.

TODO(d.maslennikov): описать маскирование данных

примечание

Для уменьшения нагрузки:

Пишите логи именно так, как вы их будете хранить и анализировать. Все поля надо записать прямо из приложения, которое генерирует логи. Часто вместо этого делают пайплайн, который добавляет некоторую информацию в логи, например имя ноды, на которой было запущено приложнеие. Для этого придется перечитывать файлы логов, парсить из, десериализовать, добавить нужную информацию, сериализовать и записать снова. На это может уйти существенная доля ваших ресурсов.

Пишите только важную информацию. Большая часть логов скорее всего вам почти никогда не понадобится, но на их обработку будет тратиться много ресурсов.

Пишите только структурированные логи — очень редко вам будет нужно читать непостредтвенно сообщения. Как правило вам нужны лишь численные значения и идентификаторы события. Парсинг текстовых сообщений в дальнейшем опять приведет к расходу ресурсов, как правило для этого строят полнотекстовые индексы, но их часто не хватает и придется использовать регулярные выражения для разбора, а это медленно и требует огромного количества ресурсов.

Учитывайте, как система логгирует во время сбоя — возможно вам не надо много однотипных записей, а можно просто указать, что много ошибок происходит по одной и той же причине — это потребуется реализовать в коде приложения.

Если логи используются для получения разнообразной статистики, а у вас очень много запросов, то вам не нужно логировать все записи. Достаточно логгировать только какой-то процент. Статистику вы сможете вычислить в любом случае довольно точно и секономите много ресурсов. Так можно логгировать только половину, или даже только один процент и меньше событий. Реализуя такое поведение логируйте не каждые n событий, а случайные события с вероятностью 100/n % — так меньше вероятность породить регулярный паттерн, который консистентно повлияет на статистику.

Логи, как API

Структурированные логи со временем часто будут обрабатываться сложной логикой. Вы захотите детектировать разные ситуации по содержимому логов и такая логика будет все сложнее и ее будет больше. Со времением любое изменение в логгировании будет очень сложно сделать, так как это будет ломать данную логику. Разработчики часто довольно вольно относятся к логгированию, считая, что это что-то опциональное и они могут менять логгирование в любой момент как захотят. Но с учетом написания логики поверх логов это становится уже не так. Фактически логгирование становится неким отложенным API вызовом в системы, которые анализируют ваши логи. И относится к логгированию лучше так же, как и к API: делать продуманный дизайн логгирования, версионировать, документировать, удерживать совместимость сколько необходимо, понимать и трекать зависимости.

Даже то, что поверх логов строят мониторинг и некоторое сочетание логов приведет к алертированию дежурных уже говорит, что логи это еще один способ сделать вызов в систему логгирования.

Метрики

Метрики представляют собой именованный временной числовой ряд. То есть у нас есть некоторое имя, и для моментов времени с некоторым интервалом — некоторое числовое значение.

Есть два способа предоставления метрик приложением — переодически писать (push) метрики в централизованное хранилище или предоставить API для забора метрик, предоставляющий мгновенное значение метрик, которым будет пользоваться приложение, которое собирает метрики (pull). И тот и тот метод чаще всего равнозначны, но в некоторых случая предпочтительнее либо один, либо другой.

Имена метрик в популярных системах, как правило имеют теги — идентификаторы, котрые позволяют в дальнейшем объединять (агрегировать) значения метрик.

Метрики часто позволяют существенно экономить ресурсы. Например, у нас очень нагруженная система, которая обрабатывает 100000 запросов в секунду, а нам надо знать сколько запросов обработало наше приложение в минуту. То если мы запишим в лог информацию о каждом запросе — будет очень много данных. А в случае метрики это всего одно число в минуту. Но при этом в случае логов у нас есть больше информации и мы может пересчитывать нужную нам статистику разными способами, в том числе и по данным, которые мы собрали до того, как захотели ее посчитать. В случае метрик же такое весьма ограниченно и их нужно проектировать заранее. То есть логи это часто более детальная информация, а метрики — агрегированная, сжатая.

Часто используемые функции для агрегирования: count (количество пришедших запросов), среднее (среднее время выполнения запроса за интервал времени), медиана (и вообще перцентили, например, 95 перцентиль времени выполнения запроса), максимум (максимальное время выполнения запроса), минимум (минимальное время выполнения запроса).

Некоторые из них очень легко реализовать и они потребляют мало ресурсов. Так для подсчета количества запросов нужно хранить и инкрементировать только одно число, для среднего выполения запроса на интервале — два числа: количество и суммарное время выполнения всех запросов. При этом для среднего лучше собирать отдельно количество и суммарное время выполнения запросов для одной ноды, так как оба этих значения легко агрегировать по нодам — просто сложить значения со всех нод, а вот среднее уже невозможно агрегировать, если оно известно для каждой ноды отдельно (но можно если у вас есть среднее и количество запросов на каждой ноде отдельно).

Другие реализовать намного сложнее и они требуют существенных ресурсов. Так для расчета перцентиля на интервале потребуется хранить все значения на интервале. К тому же перцентиль нельзя потом агрегировать ни по времени ни по нодам, а только рассматривать его отдельно по нодам, как он был собран. Тем не менее на практике часто считают перцентили, так как это дает много ценной информации о работе системы. Хранение всех значений на интервале может требовать много памяти (некоторые системы могут обрабатывать сотни тысяч запросов в секунду и потребуется хранить миллионы значений для рассчета перцентиля за минуту только для рассчета одной метрики), поэтому некоторые библиотеки реализуют приблизительные статистические методы рассчета перцентилей, что экономит ресурсы, но может ввести в заблуждение в некоторых хитрых случаях.

Как правило мы собираем метрики с постоянной периодичностью, которая на практике колеблется в пределах от 10сек до 5 минут (чаще 30 секунд - 1 минута).

Метрики бесполезны, если значение метрики меняется в разных направлениях (увеличивается и уменьшается) чаще, чем мы собираем метрику. Такие быстро меняющиеся значения не подходят для обработки метриками. Примером может служить число активных запросов. Если на обработку одного запроса вы тратите меньше секунды, а всего у вас тысячи запросов в минуту и метрику вы собираете раз в минуту, то собранные значения будут полностью неинформативны. Не подвержены этому метрики, которые монотонно увеличиваются, так например общее число запросов будет информативно при любом количестве этих запросов и любом интервале сбора метрик.

Быстро меняющиеся метрики часто возникают там где мы захватываем и отпускаем ресурс. Как правило мы хотим знать насколько мы располагаем запасом (утилизацию) по этому ресурсу (это может быть CPU, соединения для API вызова, всевозможные блокировки, которые часто захватываются и отпускаются и т.п.). Для этого считают не количество занятых ресурсов сейчас (занят или нет CPU сейчас), а время, которое ресурс пробыл в занятом состоянии. Очевидно оно не может быть больше календарного времени. Видя сколько был захвачен ресурс в единицу календарного времени мы можем судить об утилизации ресурса. Такая метрика монотонно увеличивается. В примере с CPU, если у нас 10 ядер и они за последнюю минуту проработали 4 минуты, то у нас используется 40% вычислительных ресурсов (все 10 ядер могут работать 10 минут в минуту).

Если логи имеют тенденцию расти в объемах, то метрики растут в количестве самих метрик. Как правило системы обработки метрик чувствительны к количеству мерик, что они агрегируют и обрабатывают. На практике часто можно иметь десятки и сотни миллионов метрик в системе мониторинга. Одна из распространенных ошибок при сборе метрик — попадание идентификатора пользователя или, еще хуже, запроса в идентификатор метрики. В этом случае нам очень легко получить миллиарды новых метрик. Систему мониторинга надо обязательно защитить от таких взрывов. К сожалению, многие опенсорсные решения не содержат никакой защиты от таких случаев — приходится изобретать разные решения, мы (в Тинькофф) для этого написали свой сборщик метрик для этого. Даже без таких ошибок метрики имеют тенденцию к разрастанию, если вы используете много тегов. Так если ваше приложение продуцирует 1000 метрик, при этом у вас 3 датацентра по 100 нод в каждом, то всего у вас будет уже 1000 _ 3 _ 100 = 300000 метрик с одного приложения!

Сейчас наиболее популярный "стандарт" отдачи метрик приложением — OpenMetrics. Формат изначально был придумал для Prometheus, но с популярностью данной системы мониторинга его стали поддерживать другие системы.

TODO(d.maslennikov): описать типы метрик (gauge, счетчик, гистограмма)

Долгосрочное хранение метрик

Часто мы хотим хранить метрики очень долго: год и даже несколько лет. Это помогает видеть медленные тренды. Такое долгое хранение сопрежено с существенными техническими сложностями. На таком времени хранения это очень много данных.

Одно из решений позволяющее уменшить количество хранимых данных — downsampling. Мы пересчитываем метрики, как если бы они собирались

Визуализация в мониторинге. Дашборды

После того, как мы собрали логи и метрики нужно научиться их анализировать. Для этого чаще всего используют визуальное представление в виде графиков, столбчатых диаграмм, heatmaps, цведовых индикаторов и других способов представиления информации. Наборы таких представлений объединяются в дашборды. Наиболее популярная система построения дашбордов среди открытых систем — Grafana.

Дашборды часто имеют параметры, меняя которые можно модифицировать отображаемые данные: скрывать и добавлять данные с определенных нод, выбирать информацию по интересующим API вызовам и подобное.

Часто дашборды делают так, чтобы сравнивать одну и туже информацию с разных нод, чтобы выявлять аномалии между разными нодами.

В больших системах визуализации часто превращаются в нагромождение линий с разных источников. Это приводит к более сложному анализу информации. Следует стремиться к как можно меньшему количеству линий на одном графике. К тому же даже люди с нормальным цветовым восприятием не могут четко различить больше 8-10 цветных линий. Если же в команде есть люди с нарушенным цветовым восприятием (их намного больше чем кажется), то линии становится совершенно невозможно различит линии.

Алерты

В современном мире никто не смотрит на дашборды 24/7 — у людей есть более интелектуальные и интересные задачи. Вместо человека за показателями следит специальный код. Мы будем называть такой код триггерами, потому что они порождают уведомления инженерам, что случилась ситуация требующая срочного внимания — алерты, само уведомление, которое получает инженер, мы будем называть пейджем.

Триггеры могут быть как совсем простые, например сообщить, что свободного места на диске осталось менее 80%. Так и довольно сложными, учитывающими много параметров (значений метрик и логов), время суток, день недели, выходные и праздничные дни и многое другое.

В последнее время есть возможность вычислять типичное поведение метрики с помощью машинного обучения и триггерить алерт при отклонении от типичного поведения. Это существенно упрощает создание триггеров, что есть довольно длительный и трудозатратный процесс, но изменение типичного поведения часто не означает ничего плохого, а может быть вызвано простыми естейственными причинами (релиз новой версии, которая может быть более оптимальной или просто делать что-то продругому).

Часто алерты плохо проетируют и добавляют туда много лишних условий для страбатывания, аргументируя, что "мы хотим знать, когда это происходит", "нам интересно это знать и не мешает". Это ошибочно. Среди многих неважных алертов действительно важные легко теряются. Правило должно быть таково: уведомлять надо только о важных ситуация требующих обязательного реагирования инженера на каждый факт обнаружения такой ситуации (то есть простые информационные алерты должны полностью отсутсвовать — для этого можно сделать дашборд с текстовой информацией).

Должно быть два канала нотификации для срочных и несрочных алертов. Несрочные это те, которым надо обязательно заняться, но можно подождать до рабочего времени. Срочными надо заниматься немедленно. Срочные алерты должны доставляться по специальному каналу (это не может быть просто мессенджер или e-mail, должен звонить телефон, иначе они всегда будут пропускаться) и факт их принятия должен подтверждаться. Так же разумно настроить процесс эскалации, если дежурный инженер не принимает пейдж. Подробнее в теме про дежурство и процессы в SRE командах.

Гигиена нотификаций

Люди склонны переоценивать важность уведомлений, согласований и подобного.

Профессионалам должна быть знакома продуктивность работы в потоке и подробно рассказывать об этом не тема данной статьи. Но в целом важно уметь работать с минимумом отвлекающих уведомлений — примем это за некую данность.

Сейчас есть четыре основных канала связи сотрудников друг с другом:

1. Назначить встречу в календаре
2. Позвонить (аудио/видео связь)
3. Написать в мессенжер
4. Написать E-mail

Еще один важный момент — у человека есть некий лимит внимания. Не сможет человек отвлекаться, реагировать, понимать и запоминать больше некоторого лимита в день.

Для SRE много дополнительных нотификаций дают алерты. Делать алерты на всякий случай и на посмотреть — убивать свою продуктивность. Необходимо оставлять только действительно важные сообщения каждое из которых должно быть внимательно прочитано и обработано.

TODO(d.maslennikov): написать про трассировку